How to turn security events from QRadar into self-healing actions on infrastructure

Here for your perusal is a self-contained solution that provides a service AL that listens for incoming requests coming from QRadar Event Rules. You write your own ALs to perform actions based on various events, using data shared by QRadar in the event action request JSON. Note that this is part of the Guardium bundle, leveraging it to automatically perform reconfiguration, like locking suspicious user credentials, or closing off access to a resource pending further analysis.

https://github.ibm.com/eddie-hartman/QRTrigger

Enjoy!

SDI, TDI, what's in a name

When IBM acquired the integration powertool back in 2002 it was called 'IBM Data Integrator'. Then after a bit of political squabbling, it was moved to the Tivoli brand and renamed 'Tivoli Directory Integrator'. Now, after its move to the Security brand a few years back, the name became 'Security Directory Integrator'.

I just think of it as 'Integrator', although my fingers still type 'TDI'. Old habits. And it is still being used for a wide variety of scenarios from cloud application integration to infrastructure rewiring.

So don't let the name fool you.

How To Ask Smart Questions

Although this article is particularly about asking hackers there are some universally relevant pearls here that are ring particularly true today:

http://catb.org/~esr/faqs/smart-questions.html

It's easiest to go for the quick fix when it comes to information gathering. It's apparent in the alarming number of people who's primary news source is social media, and it's highlighted nicely in this article about how Google Maps is making us dumber:

https://www.vocativ.com/418342/google-maps-gps-navigation/index.html

In particular, it's about exercising the gray cells to uncover the desired knowledge. This list of steps from the first article above is by no means exhaustive:

--- excerpt

Before You Ask

Before asking a technical question by e-mail, or in a newsgroup, or on a website chat board, do the following:

1. Try to find an answer by searching the archives of the forum or mailing list you plan to post to.
2. Try to find an answer by searching the Web.
3. Try to find an answer by reading the manual.
4. Try to find an answer by reading a FAQ.
5. Try to find an answer by inspection or experimentation.
6. Try to find an answer by asking a skilled friend.
7. If you're a programmer, try to find an answer by reading the source code.

---

Of course, sometimes speed is critical. But a little forethought and investigation will help make your question easier and faster to answer.

And since I see the world through TDI-colored specs, I going to add that

• You include 'java' to any searches involving TDI research and troubleshooting (step 2)
• The AL Debugger is a great tool for step 5
• The TDI user forum is where many of your skilled friends can be found* :)

*Link here: www.tdi-users.org

SDI/TDI as a Windows Service

NOTE: You must remember to copy the ibmdiservice.exe and ibmdiservice.props files from the <InstallDir>\win32_service folder to your Solution Directory (soldir) before you run the service installer.

It is a common mistake to run the service installer from the wrong folder - i.e. not your soldir. Often this is done from <InstallDir>\win32_service where the .exe and .props files are found.

And if you don't know what the soldir means to an SDI/TDI Server, please have a look here: https://ibm.biz/BdjiM6 for this and much more Integrator Know-how you should know.

Note also that you can fire up the Config Editor (CE), ensure the 'Default' Server document points to the same port, install folder and solution directory, and monitor and operate the running server.

Thinking about agility

My favorite agile tool is TDI (and please forgive an old man for having trouble shifting to 'SDI'). Not only can I whip together integration service prototypes faster than anything I can do in Java (Spring), or Python or TurboPascal, but I can also build Ops features this way. Monitoring and remote control (pause, restart, failover/failback) for enabling auto-healing, or at least making the solution cheaper to own. As you know, the cost of building a service can quickly be dwarfed by the cost of owning that service over time.

My recent history as a GBS consultant has made DevOps a focus of my job and I have been applying modern tools and techniques to TDI. This includes using git for source management, which ties nicely into CI/CD pipelines. Jason, of Adventures in TDI and TDI support fame, helped me to install eGit in my SDI CE both on Windows and Linux. Git was created by Linux Torvald who gave us Linux, so it's really easy, fast and a de facto standard.

Of course, to build a DevOps pipeline I needed a 'TDI compiler' to turn the TDI workspace Project folder structure and files into the one big Config xml file that the TDI Server needs. So I wrote this Python script. You run it from a command line like this:

    python configify.py -p <Project path>

With these optional parameters:

     -h                 Help & usage instructions
     -v                 Display version
     -c <path>     Write the config to the file specified by <path>
     -n <name>   Set the Solution Instance name (web api) to <name>
     -o                 If present, overwrite the resulting config file

You can grab the script by installing the git commandline and typing someplace where you want the files downloaded:

       git clone https://github.com/eddiehartman/configify.git

Once this was working I focused on Dockerizing a TDI solution. This was pretty simple to do, so I first made a default TDI (SDI) image and then can roll new Dockerfiles to create images based on specific solutions (configs). Then I pushed this up to a Kubernetes cluster and tested it. Pretty simple and the answer to HA and scalability, if you're willing to design for componentization.

Now my next step is to tie this altogether in a pipeline for continuous integration and delivery. Thinking of using Jenkins since I have used it before and have lots of old Jenkinsfiles to copy/paste from. Once I have everything working I though I might quick video.

Sound like a plan? Interested? I know that TDI'ers are often engaged in quick one-off integrations, like security Adapters for ISIM or IGI or PIM. However, for those delivering services (infrastructure wiring) I would think DevOps is important. I look forward to hearing back from y'all :)

Collecting my ramblings on Connector Loops in one place

November 7, 2013 - Connector Loops and why you're gonna love them

September 30, 2013 - Why Loops Instead Of Lookup Mode 

November 7, 2013 - Why Connector Loop

June 8, 2010 Loop a Connector today

TDI Getting Started and Ensuring Basic Understanding

The Basics

• Install TDI (https://ibm.biz/BdjsLw) locally to your laptop. This lets you customize your TDI environment easier. If you can't get a licensed version, start with the free version (https://ibm.biz/BdjiMg). It's fully functionally, will give you time needed to get started solving with TDI, and the license file can be replaced when you get yours.
• Do NOT install under Program Files on Windows, or any other auto-secured folder. Install to C:\TDI\V7.1.1 (and V7.2). 
• Note that you can have multiple versions of TDI installed, but each TDI Server needs to have its own Solution Directory (https://ibm.biz/BdXX8h) if they will be running simultaneously. If not then they can share a single Solution Directory. This is how I organize my TDI.
• If you are installing on Linux there are pre-installation steps as follows:
• For Redhat/CentOS:
1. yum upgrade libstdc++
2. yum install libstdc++.i686
3. yum upgrade zlib 
4. yum install zlib.i686
• For Ubuntu
1. sudo apt-get update
2. sudo apt-get install libstdc++5 libstdc++5:i386
3. touch /etc/inittab
4. remove /etc/inittab after installation

• Install the latest TDI Fixpack, linked to from the TDI portal page (http://www.tdi-users.org)
• Quick Guide to installing a Fixpack: 
• Unzip the Fixpack zip and grab the file named TDI-7.1.1-FP000*.zip (or SDI-*) and copy it to the TDI installation folder. 
• Grab the UpdateInstaller.jar file from the zip as well and copy it to the maintenance sub-folder of the TDI installation directory.
• Make sure TDI is NOT running and then open a commandline window to this folder. Execute the following:

                             (example for installing FP6 on TDI 7.1.1)
                             Windows: bin\applyUpdates -update TDI-7.1.1-FP00006.zip
                             Linux:        bin/applyUpdates -update TDI-7.1.1-FP00006.zip 

• Learn TDI. Anyone learning TDI is recommended to *work through* the tutorial exercises in the Getting Started Guide PDF (https://ibm.biz/BdsCVN) or online (https://ibm.biz/BdjsLU). 

• Make sure you understand the basics:
• You need to know what an AssemblyLine is (https://ibm.biz/BdjsQL). In addition to being a com.ibm.di.server.AssemblyLine (https://ibm.biz/BdjiMu), every AL is also a Java Task. TDI is pure Java, and you can mix and match standard and custom libraries, and use techniques you know from Java development.
• Know how to watch data flowing with the AssemblyLine Debugger (https://ibm.biz/Bdjiy3).
• Grab this PDF detailing the workflows in TDI (https://ibm.biz/BdjeQm) and keep it close while building solutions and exploring options.
• Understand that AssemblyLine Components are simply the puzzle pieces you can click together to form AssemblyLines. AL Components can be of different types, like Connectors (https://ibm.biz/BdjiVw), Scripts (https://ibm.biz/BdjiVt) or Attribute Maps (https://ibm.biz/BdjiVU).
• See how Connector Interfaces (https://ibm.biz/BdjsQF) are attached to AL Components in order to connect to data. Connector Interfaces are often referred to just as specific 'Connectors', like LDAP, Database or MQ.
• And get to know the AssemblyLine Debugger (https://ibm.biz/Bdjiy3). With it you can answer a lot of questions that arise when you're working to get data where it needs to be.
• You need to know how to use the various Entry objects TDI gives you (https://ibm.biz/Bdjs9f). And you can create your own if you want to, for example, to accumulate data between iterations.
• As well as understand how Attributes store data (https://ibm.biz/Bdjs9g). Hint: the Debugger shows you.
• Of course, understand how the built-in flows of the AssemblyLine and all Connector Modes (like Iterator, AddOnly and Update) let you customize behavior through scripting in Hooks (https://ibm.biz/Bdjs9a). Error Hooks and Reconnect configuration are keys to a robust dataflow.
• You'll want to get familiar with the 'system' object (https://ibm.biz/BdjiyW). It gives you handy functions for all sorts of things like date formatting/parsing, skipping or repeating the current Work Entry, and invoking commandlines. Note, full JavaDocs are installed with your TDI: <InstallDir>/docs/api/index.html
• Loops, in particular Connector Loops (https://ibm.biz/BdjiM9 and https://ibm.biz/BdjiMC), can be game changers.
• Last but far from least, you should be comfortable with Javascript (https://ibm.biz/BdjsQV).
• Follow these links to learn more, and note that even content labelled '7.0' or '7.1' applies for all versions of TDI: 
• User forum (https://ibm.biz/Bdi83A)
• Internal IBM forum (https://ibm.biz/Bdi83k)
• User portal (http://www.tdi-users.org) 
• Tutorial videos  (https://ibm.biz/BdHh9k)

Solution Guidelines - The Basics

• Create a project folder under the Solution Directory for each solution. Put all support files (Config, properties, etc.) in this folder and always use relative paths to reference these files. This makes your solution easy to package and portable (https://ibm.biz/BdXX8h).
• Use the Resources library to define AL components (Connectors, Scripts, Attribute Maps etc) so that they can be re-used in multiple AssemblyLines. Or even Pooled if you want to limit connections.
• Configure Connectors for Connection Errors and Auto Reconnect (https://ibm.biz/BdjiMP). Usually you only want AutoReconnect for Connection Lost situations. You can even define which Exceptions a Connector should consider as 'Connection Lost', initiating Auto Reconnect behavior (https://ibm.biz/BdjiMY).
• Implement an Error Handling strategy for your solution (https://ibm.biz/BdjiMS). It could be to simply to log all errors and continue (when possible). If so, try to include as much relevant information as possible, including the original Error you are respondng to.

• For an Error Hook in a Connector, it could look like this:

var data = "\n##DATA\nwork: "  + work.toJSON(); // handy format for later parsing
if (typeof conn != "undefined") { data += "\nconn: " + conn.toString(); }
if (typeof current != "undefined") { data += "\ncurrent: " + current.toString(); }
var where = thisConnector.getName()
                     + " (" + thisConnector.connector.getClass() + ")"; // Connector Interface
throw "Error for " + where + "\nerror: " + error.toJSON() + data;    

• Whereas a try-catch block would look like this:

try {
    // doing something that might exception out
} catch (ex) {
    var data = "\n##DATA\nwork: "  + work.toJSON();
    if (typeof conn != "undefined") { data += "\nconn: " + conn.toString();
    if (typeof current != "undefined") { data += "\ncurrent: " + current.toString(); }
    throw "Function foo(bar) failed, bar = '" + bar + "'\n" + ex + data;
}

• Watch this bullet for future content...